Hello all. Busy weekend, so this post comes out today.

Occasionally I throw up a post that uses shellcode, but I haven’t quite explained it in detail. So, that’s what this post is about.

Shellfish Systems and Security is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Shellcode is referred to as such because it is commonly used as code that opens up a “shell” or a command prompt that an attacker can use remotely. Nowadays, shellcode is used as a term for raw executable code that isn’t built into an executable.

Here’s an example of some x86 shellcode.

All this does is add the 2 parameters of the function and then return the sum. Here’s what it looks like when disassembled (I used this online disassembler).

And here’s what the shellcode actually looks like before it gets compiled.

Shellcode is just the assembly (the machine code) of a function. In some cases, it doesn’t even have to be an entire function. For an example, in thread hijack injections, there is no prologue/epilogue because the IP is immediately set to another location during the injection.

Shellcode is very useful for exploitation and injection. It’s difficult to trace as there’s no owning module of it, and it’s usually very small. All you need to do is figure out how to get it into a process and then execute it.

Now, you may be thinking to yourself “wow that is so much easier and much more efficient than writing an entire DLL”. You’re right. But, there’s a few things shellcode can’t do quite as well.

Let’s look at this function.

Can you write some shellcode that does this? Yes, you could. But it would be a bit complicated.

Before I explain why, let’s look at the disassembly of MyLoadLibrary.

When I compiled the function and then disassembled it, it presented the fact that LoadLibraryA is an import held at address 0x402000. This is not a guarantee. LoadLibraryA can be anywhere, and the one of only surefire ways to figure out where it is is to parse the Import Address Table (IAT).

So, in order to create shellcode to call LoadLibraryA, you would have to write this (given you are able to pass the base of the module as a parameter):

Oh and you would have to rewrite that should you want to perform the same thing in x64.

Anyways, remember IAT hooks? Well, the IAT is what is being parsed here to find LoadLibraryA. And also, if the program doesn’t import LoadLibraryA? You’ll have to parse it to find GetModuleHandle(A/W) and GetProcAddress so you can get the address of LoadLibraryA manually (most malware does this BTW).

You could also use the PEB and walk the Ldr to find kernel32.dll and thus its exported LoadLibraryA as well.

If you’re lazy (or smart?), you could find a way to pass the function pointer as a parameter to the shellcode.

Anyways, the point is that shellcode has a purpose. It is small, it is versatile, it is difficult to track, and there’s libraries with tons of useful shellcode on the internet (1, 2).

“How do you write your shellcode, Crawfish?”

I do it in a lazy way. I have a properly setup Visual Studio project with optimizations turned off, then I write the shellcode function(s), compile them, and then stick the .exe into IDA to extract the bytes of the function I wrote. If I need to be fancier with the shellcode, then I adjust from there with online assembler/disassemblers.

There’s a couple of things to be wary of when writing your own shellcode:

Hopefully you already know that strings are just pointers to byte arrays in the data section, right? Anyways, if you wanted to use a string in some shellcode, you would have to write some code that looks like this, and then adjust it manually.

Pause. What is decltype?

decltype is a C++ keyword that automagically retrieves the type declaration of a variable at compile time. In this case, it would convert decltype(&::MessageBoxA) into int(WINAPI*)(HWND, LPCSTR, LPCSTR, UINT), but that would be a pain in the ass to write and also figure out, so decltype is our friend here.

Let’s assume that msgboxptr is the pointer to the function MessageBoxA.

This is what the shellcode would look like (in x64):

Why x64?

x64 assembly has RIP-relative addressing, which means that you can use reference memory by offsetting RIP by the distance between it and the memory you are trying to access. x86 doesn’t have this feature, so x86 shellcode has to reference the actual offset of the memory location from the base of the module, which might be difficult to find.

TLDR; it was easier to write in x64.

Instructions 9 and 15 are referencing the 2 strings that are input into MessageBoxA. They aren’t filled out yet as we need to add both “Hello World!” and “Hi” into the shellcode so that they can be referenced appropriately.

“Hello World!” expands to 48 65 6C 6C 6F 20 57 6F 72 6C 64 21 00“Hi” expands to 48 69 00

Now, your shellcode will look like this:

48 89 4C 24 08 48 83 EC 38 48 8D 05 00 00 00 00 48 89 44 24 28 48 8D 05 00 00 00 00 48 89 44 24 20 45 33 C9 4C 8B 44 24 20 48 8B 54 24 28 33 C9 FF 54 24 40 48 83 C4 38 C3 48 65 6C 6C 6F 20 57 6F 72 6C 64 21 00 48 69 00

Almost done. All that is left is to add the strings to the LEA instructions.

This involves some math, but I just use Python.

Voilà, address-relative shellcode!

Similar to the string problem, functions can be called via a relative address (E8 opcode) and also by absolute address (FF 15). Relative calls would be useful for calling functions within the shellcode, and absolute calls would be useful for calling into the target process. In x64, you may run into an issue that was touched on in the Emplacement Hooks post. If you’re a free subscriber, I’ll just copy and paste the summary here.

“Relative call instructions cannot exceed 2 gigabytes in either direction of the current address. If you have an instruction at address 0x7FF780000000, you cannot perform a relative call to any function < 0x7FF700000000 or > 0x7FF87FFFFFFF. The only way to reach functions beyond that range is to MOV the address into a register and then CALL the register (like in a virtual function!). x86 programs are limited to 2 gigabytes in size (because x86 = x32, which is 32 bits/4 bytes and the highest value of a signed 4 byte integer is 2.147 billion AKA 2 gigabytes). x64 programs can be much larger, so you aren’t guaranteed to have your DLL hook function within 2 gigabytes!”

TLDR; if in x64, you may want to call a function via a register if calling into a program.

That’s all for this post. I wanted to shed some light on the machinations of shellcode for you all.

Have a great weekend!

Go!

-BowTiedCrawfish

Shellfish Systems and Security is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.